PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 4/USEnet 4.46

Text File | 1988-06-15 | 28.4 KB | 740 lines | [TEXT/ttxt]

19-Apr-88 17:17:27-PDT,29760;000000000000
Return-Path: <[e-mail]>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Tue, 19 Apr 88 17:14:55 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa13500; 19 Apr 88 17:49 EDT
Received: from relay.cs.net by RELAY.CS.NET id aa24153; 19 Apr 88 17:39 EDT
Received: from sdr.slb.com by RELAY.CS.NET id ag24118; 19 Apr 88 17:35 EDT
Date: Tue, 19 Apr 88 17:20 EDT
From: Jeffrey Shulman <[e-mail]>
Subject: Usenet Mac Digest V4 #46
To: [e-mail], [e-mail]
X-VMS-To: in%"[e-mail]",in%"[e-mail]"

Date: Tue 19 Apr 88 17:20:25-GMT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V4 #46
To: Usenet-List: ;
Message-ID: <577473625.0.SHULMAN@SDR>
Mail-System-Version: <VAX-MM(218)+TOPSLIB(129)@SDR>

Usenet Mac Digest     Friday, April 1, 1988          Volume 4 : Issue 46

Today's Topics:
     Re: Memory Management (was Quickergraf bugs...)
     Re: When to draw rect around List in DLOG
     Bulldozer cursor?
     Why does my keyboard stick in UPPERCASE?
     xmodem->versaterm at 1200
     Re: GATT declares U.S. - Japan chip pact illegal
     Memory Checking Programs
     Re: GATT declares U.S. - Japan chip pact illegal
     Macintosh Statistics Packages
     Help! TextEdit Programming Problem - "nLines" (2 messages)
     Interprocess communications (2 messages)
     XNS
     Re: Macintosh Statistics Packages
     Re: Why does my keyboard stick in UPPERCASE?
     New LaserWriter II SC
     Re: Why does my keyboard stick in UPPERCASE?
     Floppies (made in the USA) (look for the union label)
     Re: Interprocess communications

----------------------------------------------------------------------

From: [e-mail] (Larry Rosenstein)
Subject: Re: Memory Management (was Quickergraf bugs...)
Date: 29 Mar 88 22:24:01 GMT
Organization: Advanced Technology Group, Apple Computer

In article <[e-mail]> [e-mail] (Stew Rubenstein)
writes:
>
>toolbox needs the memory for.  You have to assume that any request is
>critical.  This is not far from the truth - memory allocation failures
>are handled very poorly by the toolbox.  In my apps, I have routines
>Critical() and NonCritical(), which clear and set a flag checked by

In MacApp we do a similar thing, except critical requests are called
"temporary", and non-critical requests "permanent".  This reflects
whether or not the memory is for the user's document, and cannot be
reclaimed later.

Temporary (critical) memory consists of code segments, defproc
resources, packages, etc.  By default all requests are temporary (ie,
critical), although the programmer can change the state of the flag as
needed.  We also provide a call NewPermHandle to allocate a permanent
handle.

>allocations in my own code.  Another useful trick is to allocate a
>couple of buffers at the start of your program so that you have
>something to release when the growzone proc is called.

In MacApp, the programmer can specify the size of the temporary and
permanent reserves.  The permanent reserve is just a last chance piece
of memory that the grow zone proc will release if all else fails.  When
this memory is gone, then memory is really low and MacApp will put up a
message telling the user this (overridable of course).  The size of this
reserve is usually only 4-10K.

The temporary reserve is more interesting.  The programmer sets this
size based on the maximum amount of temporary memory the program will
need at any time.  MacApp will ensure that this amount of memory is
available.  We add up the currently loaded segments, defprocs, etc.; if
the sum is less than the reserve we allocate a handle to make up the
difference.  (This is so memory is not wasted trying to maintain the
reserve.)

If the programmers sets the temporary reserve correctly, then the
program cannot bomb because a code segment, package, etc. cannot be
loaded.

>Finally, it's important to preflight every memory request that you
>can.  For example, before you call a routine in another segment, do a
>GetResource on the right CODE segment and check to see it succeeds.  A
>failure to load a CODE segment causes an immediate system error.  The

This approach will work, but it makes it difficult to change the
program's segmentation without having to change the code.  Also, in the
case of MacApp, we could not know how the final program would be
segmented, since we can't know what code the developer will be writing.

In MacApp, you specify the name of the segments that form the maximum
code working set, as well as an absolute number to add in.  This
information is in resources so that it can be changed easily.  (The
MacApp debugger helps you determine which segments comprise the maximum
working set.)  The idea here is that the maximum working set might
change in value, but the segments that make up the working set should be
consistent.

The programmer can also change the size of these reserves
programmatically.

The only kind of preflighting we do in MacApp is when opening a DA.  We
make sure that there is enough permanent memory for the DRVR resource,
and then we open the desk accessory with the temporary flag on.  This
helps ensure that the DA won't bomb when opening (in case it doesn't
check its memory allocations).

After the DA is opened, we check to see if our guaranteed temporary
reserve has been exhausted.  If so, then we immediately close the DA and
report an error.  (This assumes that the DA cleans up after itself, but
there is nothing an application can do with such unfriendly DAs.)

Region operations that occur in the normal course of events
(invalidating a window) are considered temporary, and the temporary
reserve should handle them.  This would only be a problem if regions
were being used at the time when the maximum code working set was
loaded.

MacApp also unloads all code segments each time through the event loop,
although the programmer can mark a segment as resident and then it won't
be unloaded.  Unloaded segments stay in memory in case they are needed
again.

This memory management architecture seems to work very well.  It has the
advantage that it is generic, and doesn't have to recoded for each
application.  The programmer only has to plug in the specific parameters
of the application.  Before MacApp was released, we tested our memory
management by having the testing group stress test one of our sample
programs as if it was a product.
--
         Larry Rosenstein,  Object Specialist
 Apple Computer, Inc.  20525 Mariani Ave, MS 27-AJ  Cupertino, CA 95014
        AppleLink:Rosenstein1    domain:[e-mail]
        UUCP:{sun,voder,nsc,decwrl}!apple!lsr


------------------------------

From: [e-mail] (David W. Berry)
Subject: Re: When to draw rect around List in DLOG
Date: 30 Mar 88 02:11:07 GMT
Organization: Apple Computer Inc, Cupertino, CA

In article <[e-mail]> [e-mail]
(Jeffrey A. Sullivan) writes:
>I am maintaining a List (ala list manager) in a dialog using TransSkel.  The
>list does not have arectangle around it, so you have to draw one in.  The
>question is :  When exactly should I be drawing it in?  During updateEvent,
>ActivateEvent, before calling the SkelDialog procedure, or what?
    The way I prefer to do it is to define a UserProc which handles drawing
the dialog.  That way I'm sure that anytime it needs to be drawn it will
be.  The proc need do little more than:

    pascal void UserProc(dlog, item)
    DialogPtr    dlog;
    short        item;
    {
        Rect    rect;

        GetDItem(dlog, item, &type, &hand, &rect);
        LUpdate(whatever it's args are);
        FrameRect(&rect);
    }
--
David W. Berry
dwb@Delphi    [e-mail]    [e-mail]
Disclaimer: Apple doesn't even know I have an opinion and certainly
    wouldn't want if they did.


------------------------------

From: [e-mail] (Jay Freeman)
Subject: Bulldozer cursor?
Date: 29 Mar 88 22:53:41 GMT
Organization: SPAR - Schlumberger Palo Alto Research

The other week I was running MPW 2.02 under Apple System 5.0 (Finder
only, not Multifinder) on my Mac II, when the cursor changed to a
tolerable line drawing of a bulldozer and a lot of disc activity began.
This situation continued for a minute or so, whereupon the cursor
returned to its usual arrow shape and MPW resumed normal operation.  I
have never seen the like before or since.

It could have been a virus doing something wicked, but it has been long
enough (several weeks, several hundred hours of active on-time) with no
obvious evidence of disaster, that I doubt it.

If I had to make a guess, I would say that either MPW or the Finder had
decided to do a thorough heap-compaction and was writing out a large
temporary file to disc as part of the process; the bulldozer cursor
seems appropriate for pushing a big jumbled heap around, and duplicating
the heap to disc is a fairly common trick in garbage-collection
algorithms.  However, I could not find any obvious reference to this
behavior in any of my manuals.  (On the other hand, considering the size
of the MPW manuals and of _Inside_ _Macintosh_, I may well have missed
something.)

Does anyone either (a) recall seeing this happen or (b) know what was
going on?


                    -- Jay Freeman


<canonical disclaimer -- this posting represents my personal opinions
only>


------------------------------

From: [e-mail] (Vincent Heuring)
Subject: Why does my keyboard stick in UPPERCASE?
Date: 30 Mar 88 15:59:57 GMT
Organization: University of Colorado, Boulder

Every few times I run an application on my Mac II, the keyboard shifts
to upper case.  It happens at random, and all keys (not just alphas) are
shifted.  I cannot get it to revert to lower case through any
combination of caps lock, etc.  The only fix is to reboot. (Unplugging
the KB doesn't work, nor does exiting the application.)

What is the matter here?


--
-----------------------------------------------------------------
| Vince Heuring     Dep't of Electrical & Computer Engineering    |
| University of Colorado - Boulder        [e-mail]    |
-----------------------------------------------------------------


------------------------------

From: [e-mail]
Subject: xmodem->versaterm at 1200
Date: 30 Mar 88 18:05:42 GMT
Organization: UCLA Computer Science Department

I'm having problems with downloading files using unix xmodem at
1200baud, with versaterm on the mac.  If I have a 9600baud link, it
works fine with versaterm set for text xmodem.  However, at 1200baud
(home line), the download never starts, and after a while I get an error
message.  Kermit sends however work fine at this speed.  Does anyone
know a way to get xmodem working at 1200 baud, or have other
suggestions?
--
thanks,
Margot Flowers   [e-mail]   ...!{ucbvax|ihnp4}!ucla-cs!flowers


------------------------------

From: [e-mail] (Richard Champeaux)
Subject: Re: GATT declares U.S. - Japan chip pact illegal
Date: 30 Mar 88 19:20:31 GMT
Organization: Clemson University, Clemson, SC

     Ok, I'm not an economic or political expert (or an expert of any
kind :-) but I think that even if this pact isn't the best solution,
something has to be done to protect US manufacturers, and I don't think
that just scrapping the pact is a solution.
     Japanese and other asian chip producers can currently produce chips
at prices significantly less than US producers, and US producers are
having a hard time competing.  This is just great for consumers and
computer and  perhipheral manufacturers, but if it keeps up, US chip
producers will have to move to something else or fold.  Many people I
know say that the Japanese are obviously doing something right, and if
US producers can't do the same then they should get out.  In my opinion,
I think that the fact that the asian countries have a much cheaper labor
force is a significant factor.  US producers obviously can't just cut
their employees salaries in half, so some would say that they should get
out.  Ok, so we lose the IC industry, big deal. In the southeast the
textile industry (which is the south's major  industry) is taking a
beating from Korean imports.  If they can't compete, let them fold.
Everyone knows that the US car manufactures are having touble competing
with Japanese imports and therefore make poorer quality cars.  Well, if
they can't hack it, they should get out too.  Asian computer and
perhipheral manufacturers are already beginning to overtake the market.
Bye bye US manufacturers.  Hmmm, we seem to be running out of
industries.  Oh well, as long as we consumers are getting cheap
products, no problem.  Ooops, we seem to be losing jobs and can't afford
these products anymore, how'd that happen?

     Also I seem to remember reading in NewsWeek that last spring,
Japanese companies were accused of dumping chips on the US market at
prices lower than it cost the companies to produce them.  The only
reason that I've ever heard for this kind of illegal activity is to
eliminate compitition.  I've also read that the Japanese economy and
infrastructure is stacked highly against imports, and that US imports
that should be cheaper than Japanese products end up being much more
expensive by the time they get to the comsumer.

I sorry I got up on my soapbox, but you should be grateful I didn't get
into my speech on taxes.
--
Rich Champeaux
Clemson University


------------------------------

From: [e-mail] (Dave Frelinger)
Subject: Memory Checking Programs
Date: 29 Mar 88 20:00:10 GMT
Organization: Rand Corp., Santa Monica


Hello,
    Has anyone come accross a program to check memory on a MacII like
MaM Test did on Mac Pluses? If so, could you please tell me where I
might get a hold of that program?

              Thanks in advance,

            Dave



P.S.  Does anyone think that Apple ever trust its users to use a
hardware
      diagnostic program, or will we always be forced to use home grown
      hardware diagnostic applications? Even Big Blue alows normal users
to
      check on the status of their own hardware.


------------------------------

From: [e-mail] (Marc Sarrel)
Subject: Re: GATT declares U.S. - Japan chip pact illegal
Date: 30 Mar 88 23:40:54 GMT
Organization: The Ohio State University Dept of Computer and Information Science

While I agree with you that the Asian countries have a cheaper labor
force and that their economies are sometimes stacked against imports
(especially Japan's), I cannot agree that that is the whole problem.
Ask not what they are doing that is underhanded, as what we are doing
that is wrong (so that we can correct it).  I generally do not favor
protectionist policies.

Take the automobile industry as an example.  In the begining, the
Japanese gained a foothold because their cars were cheaper than American
built ones. Then, we fell further behind during the energy crisis
because our cars were less fuel efficient.  Over the years, Japanese
cars have become more luxurious, until now they rival some American Cars
in that regard.  However, with the rising Yen, those cars have become
more expensive.  But, because of the image that the American car buyer
has of Japanese quality, Japanese cars still sell well.  (However, I
think this is changing.)

Basically, there are two differences between "us" and "them" that are
important here.  First, the Japanese seem to be more responsive to
changes in the market, and they seem to be able to change quicker.  This
is not a function of worker's salaries.  Second, and more important, the
Japanese as a society seem more willing to support the long-term
technological research that is needed to make products in a more
efficient manner (or at all, in some cases such as VCRs).  (You should
watch a tape of the NOVA that was on last night about superconductors,
they made some good points about this.)

We Americans seem to do better at inventing new things, but the Japanese
are better at spending the time needed to develop these ideas into
marketable products.  Again, this has nothing to do with worker's
salaries.

I could go on about the problem of the Japanese owning businesses in
this country.  There is also the problem of worker education (or lack
thereof). These are problems that need to be addressed, but they are
peripheral to this discussion.

It all boils down to this:  In order that both societies should prosper,
we need to become more like the Japanese and the Japanese need to become
more like us.  We need to fund that long-term development research, make
sure that our work force is better educated (to keep up with changing
technology in the workplace).  And, American consumers have to change
their attitude about  foriegn products.  (A little attitude change is
better than a lot of trade  legislation.)  (Presumably a change is
attitude will bring about a change is behaviour.  ie:  we'll buy more
domestic goods.)  American companies  overseas should know more about
those markets.  Trying to sell the Japanese a product that sells well in
this country without modification is often a fatal mistake.

The Japanese, on the other hand, should change their behaviour about
imports. They _should_ open up their markets to foriengers.  (On the
other hand, American companies should learn about the sometimes baffling
Japanese system of business dealings, after all, they had to learn ours
to be a success here.)

The bottom line is that pointing the finger at Japan and crying foul is
incorrect, useless and possibly fatal.

'nuff said
--
Marc Sarrel            The Ohio State University
611 Harely Dr #1        Department of Computer and Information Science
Columbus, OH  43202-1835    [e-mail]
Disclaimer:  Hey, what do I know?  I'm only a grad student.


------------------------------

From: [e-mail] (Paul Suh)
Subject: Macintosh Statistics Packages
Date: 30 Mar 88 20:27:00 GMT
Organization: GTE Laboratories, Waltham, MA

Has anyone out there had any experiences with heavy-duty, industrial
strength statistics packages for the Macintosh?  I'm looking for
something which will hand a data set of 500 variables w/600 observations
each, and do two-stage and three-stage least squares on them.

Email responses to me and I will summarize and post.

Thanks.

                    --Paul

Try also:    [e-mail]

as an address.


------------------------------

From: [e-mail] (Greg Rogers)
Subject: Help! TextEdit Programming Problem - "nLines"
Date: 29 Mar 88 07:44:14 GMT
Organization: Tektronix, Inc., Beaverton, OR.


Can any Mac wizard shed some light on a programming problem I'm having?
My edit record (TERec) seems to completely loose track of the number of
lines of text as I'm adding characters to the text.  In other words
TERec.nLines jumps ahead by hundreds of lines as I add characters using
TEInsert.  The number of lines that nLines jumps by doesn't seem to
follow any pattern.  Line after line of text is inserted properly and
then out of the blue, nLines jumps. This seems to occur after a carriage
return ($0D) is inserted, but only infrequently. I  also follow TEInsert
with TEScroll after each ($0D) is inserted but this seems  unrelated.
Calling TECalText fixes the edit record with nLines returning to
normal, and all characters intact.  Is there some bug related to
carriage returns and TEInsert or TEScroll in these toolbox routines?

I would really appreciate any information as I can't find any
explaination for this behavior.

                    Thanks,
                    Greg Rogers


------------------------------

From: [e-mail] (Will Clinger)
Subject: Re: Help! TextEdit Programming Problem - "nLines"
Date: 30 Mar 88 20:57:38 GMT
Organization: Tektronix Inc., Beaverton, Or.

In article <[e-mail]> [e-mail] (Greg Rogers) writes:
>
>Can any Mac wizard shed some light on a programming problem I'm having?  My
>edit record (TERec) seems to completely loose track of the number of lines of
>text as I'm adding characters to the text....

I'll bet you're using a Macintosh SE.  On an SE, the lineStarts array
will be calculated incorrectly (or sometimes the system will crash) when
all of the following conditions hold:

    _TEInsert is called;
    the inserted text ends in a space;
    selEnd = teLength;
    after the text has been inserted, the (garbage) byte following the
        newly inserted text in RAM happens to contain a carriage return.

Neither the Macintosh Plus nor the Macintosh II have this bug.

The bug lies in the routine whose address is stored at $07fc.  The ninth
through eleventh instructions in that routine are:

    cmpi.b  #$0d,0(a0,d0.w)
    bne.s   ...
    addq.w  #1,d0

If you change the add instruction to a no-op, your bug will disappear.
(You may have created a different bug because this undoubtedly disables
a minor feature of TextEdit, but the new bug seems much less serious
than the old.)

I hope this helps.  The bug was reported to Apple on 10 February 1988.
--
Peace,
William Clinger
Semantic Microsystems, Inc.


------------------------------

From: [e-mail] (Dave Frelinger)
Subject: Interprocess communications
Date: 29 Mar 88 20:05:15 GMT
Organization: Rand Corp., Santa Monica


Hello,
    I have a simple question, what forms of interprocess communications
does A/UX support?  Does it use System V, B 4.X, or a both flavors of IP
communications?


            Thanks,

            Dave


------------------------------

From: [e-mail] (Gerald Ostheimer)
Subject: Re: Interprocess communications
Date: 30 Mar 88 22:36:57 GMT
Organization: Dept of Math and CS, UMass Boston.

In article <[e-mail]> [e-mail] (Dave Frelinger)
writes:
>
>    I have a simple question, what forms of interprocess communications
>does A/UX support?  Does it use System V, B 4.X, or a both flavors of IP
>communications?
>            Thanks,

To me it looks as if Apple tried to provide the best possible support
for both Berkeley 4.2 and AT&T System V (Release 2). A/UX got about as
close to being a full System V implementation as you can get without
being one. As for inter- process communications, you get all of System V
IPC (semaphores, shared memory...), but you also get Berkeley 4.2
sockets.
--
Gerald    <[e-mail]>

Permission is granted to make and distribute verbatim or modified copies of this
opinion, as long as this permission notice is preserved.


------------------------------

From: [e-mail] (Lee Moore)
Subject: XNS
Date: 31 Mar 88 05:28:39 GMT
Organization: Xerox: Webster Research Center, Rochester, NY

Since it appears that AUX has pieces of Berkeley's networking for TCP/IP
support, does anybody know if it also had 4.3's XNS protocol support?

thanks,

Lee


--
Lee Moore -- Xerox Webster Research Center, birthplace of the XGP
UUCP:        {seismo, allegra, decvax, cmcl2, topaz}!rochester!rocksanne!lee
Arpa Internet:    [e-mail]
DDN:        [phone]


------------------------------

From: [e-mail] (Nathaniel L. Beck)
Subject: Re: Macintosh Statistics Packages
Date: 31 Mar 88 17:36:04 GMT
Organization: University of California, San Diego

You might want to look at RATS. It is a time series package that is
certainly heavy duty. Does some cross-sectional stuff, but if that is
your interest you probably can do better. RATS is essentially an  old
mainframe program that got new life with the PC. They have just come out
with a Mac version. I use the PC version so I can't tell you much about
the MAC version. I have doubts about whether the interface is up to
usual Mac standards, but the statistics are first rate.

You can get RATS from VAR associaties in Evanston, IL.

Good luck.
--
Neal Beck
Dept. of Pol. Sci.


------------------------------

From: [e-mail] (Paul Suh)
Subject: Re: Why does my keyboard stick in UPPERCASE?
Date: 31 Mar 88 17:12:32 GMT
Organization: GTE Laboratories, Waltham, MA

You have probably activated the Easy Access feature by accident, hittin
the shift key five times in a row, then twice more to do a shift lock.
The short-run solution is to hit the shift key five times, which will
deactivate Easy Access.  The long run solution is to remove the Easy
Access INIT from your system folder.

Look in the upper right-hand corner of your screen, in the menu bar, for
the EA mini-icons, to the right of the MultiFinder icon if you're
running MF.  Sometimes between applications, it doesn't get properly
redrawn (bug, I guess).

                    --Paul


------------------------------

From: giaccone@ur-tut (Tony Giaccone)
Subject: New LaserWriter II SC
Date: 31 Mar 88 19:08:29 GMT
Organization: Univ. of Rochester, Computing Center


Ok Folks, we've been evaluating the new IISC laserwriter, and found some
things that seem to be real problems. The first problem ocurrs when
printing a Microsoft Excel spreadsheet. The time it takes to print this
spread sheet seems to vary from a low of 2.5 minutes to a high of over
35. Can anyone suggest any reason why there should be the amount of
variation in the  printing of the same document. The spread sheet is one
page, printed landscape mode, uses only the Times font.

The second problem is with a Microsoft Word (3.0)  document. This
document has two columns, is in Times, with screen dumps included with
1/4 inch column spacing, and 1/2 inch margins all around. When printed
on the SC it seems to expand the margins so that the right column is
pushed off the edge of the page. The inter-columnar (1/4 inch ) is
enlarged to greater than 1/4 inch, and no amount of spacing adjustment
seems to solve the problem. Not even setting the columnar spacing to
negative values (ie -0.25 inches gives more than +0.5 inch spacing
between columns). Switching measurments to picas instead of inches gives
entirely different, but still incorrect, results.

Has anyone else out there used the SC, have you noticed these or any
other  problems with the printer? What's going on here. Would someone
from Apple care to comment?


                    Tony Giaccone


------------------------------

From: [e-mail] (James Sinclair)
Subject: Re: Why does my keyboard stick in UPPERCASE?
Date: 31 Mar 88 22:34:47 GMT
Organization: GTE Laboratories, Waltham, MA

I have experienced the same problem as the original poster, except that
instead of being limited to the shift key, it also sometimes happens
with the control key or the option key.  I do not have a copy of Easy
Access in my System Folder, so I believe the problem must be coming from
another source.  Any suggestions would be greatly appreciated.

Jim Sinclair ([e-mail])


------------------------------

From: [e-mail] (Jim Campbell)
Subject: Floppies (made in the USA) (look for the union label)
Date: 1 Apr 88 04:00:15 GMT
Organization: Interactive Systems, Boston, MA

A friend of mine is interested in acquiring some 3.5-inch,
double-density, double-sided floppy disks for use on an Apple Macintosh.
  He wants them to be made in the USA by a U.S.-based company, and with
a life-time guarantee.

Scotch is the only brand he knows that corresponds to these
specifications.  Are there any other such companies?   Where can Scotch
or any other brand of these floppies be purchased, either through mail
order or in the Boston area?  Please e-mail responses.

Thanks in advanced --

            Jim Campbell
            Interactive Systems, Boston
            441 Stuart St. 7th Floor
            Boston, MA 02116
            617/247-1155

            ihnp4!     \
            harvard!    X----> ima!haddock!jimc
            mit-eddie! /


------------------------------

From: [e-mail] (Jim Kateley)
Subject: Re: Interprocess communications
Date: 31 Mar 88 16:56:59 GMT
Organization: Apple Computer Inc, Cupertino, CA

In article <[e-mail]> [e-mail] (Dave Frelinger)
writes:
>
>Hello,
>    I have a simple question, what forms of interprocess communications
>does A/UX support?  Does it use System V, B 4.X, or a both flavors of IP
>communications?
>
On page 15 of the A/UX System Overview manual, it states: "Another
important function of the kernel is interprocess commnuication (IPC).
A/UX fully supports the System V Release 2 IPC mechanisms." ... "Signals
are another form of UNIX interprocess communication." ... "A/UX supports
both System V and BSD signals"


Additionally, in the A/UX Release notes, Version 1.0, on page 1-2: "A/UX
supports two different versions of signals:  the standard V.2 and the
4.2 reliable signals.  To use 4.2 signals in  a program, issue a call to
the set42sig routine before issuing any calls to the signal function."
... "The signal-handler setting is not inherited across an exec call,
although job control and process grjoups are available to shell
programs."
--
Jim Kateley          UUCP: {sun, voder, nsc, mtxinu, dual}!apple!kateley
S,P,HnS!             DOMAIN: [e-mail]  Applelink: kateley1
Disclaimer:   What I say, think, or smell does not reflect any policy or
          stray thought by Apple Computer, Inc.

------------------------------

End of Usenet Mac Digest
************************
-------